FIG. 1 shows a simplified illustration of a 3rd Generation Partnership Project (3GPP) network architecture which is providing network access for a User Equipment (UE). In order to enable access by the UE of Internet Protocol (IP) services provided by a network operator, a Packet Data Network (PDN) connection is established via a PDN Gateway (PGW). The PGW is selected by the serving Mobility Management Entity (MME) and remains the same for the lifetime of the PDN connection. The PGW allocates an IP address for the UE and all network traffic directed to and coming from the UE is tunnelled between the UE and the selected PGW. Network traffic tunnelled via the PDN connection to the PGW may be further transmitted to the service network of the network operator or to an Autonomous System Border Router (ASBR), for example, one of the network operator's border routers constituting a peering point with other network carriers, and then further into the Internet.
Standard document 3GPP TS 22.101 V10.2.0 “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Service Aspects; Service Principles (Release 10)” defines an option for macro-cellular access networks to offload selected network traffic (for example, Internet traffic) to an IP network that is located close to the UE's point of attachment to the access network. This option is known as Selected IP Traffic Offload (SIPTO). The motivation for SIPTO is to decrease the network operator's expenses, since it is often not effective to direct the network traffic to a remotely located central PGW when the network traffic may also be offloaded to a local service network or the Internet being located close to the UE's point of attachment to the access network. Thus, offload of network traffic can reduce costs of the network operator. A similar approach is known for Local IP Access (LIPA) for the home (e)NodeB subsystem.
Two alternative technical solutions for SIPTO are supported by the 3GPP standard. The first alternative is based on selection of a gateway that is close to the UE's point of attachment to the access network for specific types of network traffic. This alternative may be realized by an architectural solution that does not require significant changes of the current 3GPP network architecture. For example, the GW address may either be suggested by the Radio Access Network (RAN) node or may be Selected by enhanced Domain Name Server (DNS)-based mechanisms. The second alternative is based on network traffic breakout from the tunnels, e.g., from General Packet Radio Service (GPRS) Tunnelling Protocol (GTP) tunnels. The second alternative requires a plurality of new functions in the 3GPP network architecture.
Document 3GPP TR 23.829 V0.4.10 “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Local IP Access and Selected IP Traffic Offload; (Release 10)” discloses a concept concerning offloading network traffic above the Radio Network Controller (RNC) in 3GPP communication networks. This concept is based on a logical function called Traffic Offload Function (TOF) that is located at a point within the access network where the network traffic offload is required. FIG. 2 schematically illustrates the TOF located at the Iu-PS interface of a 3GPP communication network, i.e., the interface that links the RNC with the Serving GPRS Support Node (SGSN). Network traffic is tunnelled between RNC and SGSN via uplink and downlink tunnels (not shown in FIG. 2) and can be offloaded by the TOF. For this, the TOF uses Network Address Translation (NAT). Based on the logical structure illustrated in FIG. 2, offloading of network traffic from home NodeBs can also be provided.
NAT is generally used for enabling communication of an IP host from a private network with the Internet. For this, a network device (e.g., a firewall) assigns a public IP address to the IP host. NAT is also used to limit the number of public IP addresses an organization or company uses. FIG. 3 schematically illustrates a NAT function that is enabling access of a plurality of internal clients, i.e., clients i, j, k, to the external Internet. For example, in case a client wants to contact a device on the Internet, it sends out IP packets containing addressing information that are destined for the device. When the IP packets pass the NAT function via the internal interface, the NAT function obtains information regarding the IP packet's source IP addresses (i.e., the internal IP addresses) and source Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) ports (e.g., 2132). Moreover, when the IP packets pass the NAT function via the internal interface, they are modified so that after passing the external interface, they appear to be coming from the NAT function. For this modification, a mapping table is provided. The NAT function records the IP packet modifications in the mapping table so that it can reverse the modifications when IP packets returning from the Internet device arrive at the external interface of the NAT function. Thus, it is ensured that returning IP packets arriving at the external interface can pass the NAT function and are not blocked.
In the mapping table shown in FIG. 3, I-IP represents an internal IP address of the NAT function, E-IP represents an external IP address of the NAT function, I-Port represents an internal port of the NAT function, and E-Port represents an external port of the NAT function. Thus, based on the mapping table, the NAT function replaces in the data packet the source internal IP address with an external address of is the NAT function, which may have been obtained from a pool of addresses. The replacement may be I-IPi→E-IP1. Optionally, the source port in the data packet may be replaced with a randomly chosen, unused port of the NAT function (for example, I-Portx→E-Porta).
Thus, neither the client nor the Internet device is aware of the IP packet modifications provided by the NAT function. For the Internet device, the IP packets appear to be coming directly from the NAT function. In particular, the Internet device is unaware that the client even exists. When the Internet device replies to the IP packets sent by the client, they are addressed to the NAT function's external IP address (E-IP) at the translation port (E-Porta). The NAT function then searches the mapping table in order to determine whether the reply IP packets match an already established connection. A match can be found in the mapping table based on the IP/port combination indicating that received IP packets belong to a connection that is initiated by a certain client, e.g., a client with the address Thereafter, the NAT function carries out modifications that reverse the modifications it has carried out on the outgoing IP packets. Thereafter, the NAT function forwards the reply IP packets to the internal client. It has to be noted that the NAT function may possess several external IP addresses to/from which mapping can be provided.
NAT of Internet Control Message Protocol (ICMP) packets may be provided in a similar manner. However, since there is no transport layer and consequently no port field in the header of ICMP packets, no source port modification is provided. Thus, two ICMP packets sent from different internal clients at the same time may be mapped incorrectly.
Moreover, with the basic NAT functions described above, various applications like File Transfer Protocol (FTP), Instant Messaging (IM), and Peer-2-Peer (P2P) applications do not work correctly from a host behind a NAT function. Since the NAT function is transparent to the host behind the NAT function, the host can communicate its internal IP address and port number in the payload (e.g., of control messages) to the external destination. However, the internal IP address and port number are invalid at the external side of the NAT function. To solve this problem, it is known to complement the NAT function with an Application Layer Gateway (ALG) which enables support of applications from behind a NAT function. For this, the ALG inspects and rewrites the IP address and port number in case this data has been found in the payload for supported application layer protocols.
NAT techniques that modify the port numbers (i.e., the transport layer header) are known as Port Address Translation (PAT) or as NAT overloading. PAT is the most common implementation of NAT. In the following description, only the generic abbreviation NAT is used for the aforementioned NAT solutions.
Document 3GPP TSG SA WG2 Meeting #76, TD S2-096667 “Offload Context Management for SIPTO and Iu-PS” discusses offload context management for SIPTO at the Iu-PS interface for the Universal Mobile Telecommunications System (UMTS). In this document, a TOF uses session offload context information for a traffic offload decision. For uplink network traffic, the TOF drags the uplink network traffic out from the GTP-U tunnel and performs NAT to offload the network traffic based on the session offload context information. At the Access Point Name (APN) level, the TOF derives a Tunnel Endpoint Identifier (TEID) from the GTP header. If the TEID is marked to be offloaded, the TOF transfers the network traffic to a defined PDN. For downlink offloaded network traffic, the TOF performs a reverse NAT function and maps network traffic to the correct bearer. For this, the TOF adds the GTP-U header with the associated TEID (which has been allocated by the RNC) and sends it to the RNC. The TOF discards returning network traffic if it cannot find a correct mapping.
When using NAT for SIPTO (as for example described in the last mentioned document), the NAT function assumes that all hosts on the local (i.e., internal) network side have a unique IP address. This is a reasonable assumption in normal network situations, since hosts having identical IP addresses cannot communicate within the local network. However, for SIPTO, there are network situations in which at least two hosts (e.g., UEs) on the local network side (i.e., below a TOF) have the same IP address so that IP address collision occurs.
For example, a plurality of PGWs may be provided in the communication network, wherein each PGW uses the same private address space coupled with the NAT function to the Internet. In this case, two UEs attached at the same access network segment (i.e., under the same TOF) but registered to different PGWs may be given the same local IP address. Moreover, for corporate APNs, a UE that is registered to a corporate Virtual Private Network (VPN) may be given a local IP address from the corporate APN that is identical to the IP address received by another UE having a different PDN connection (e.g., an Internet APN having allocated a private IP address by the PGW). In a similar manner, a PDN connection to a local service network may have an overlapping address with a PDN connection to the Internet or a corporate network. Furthermore, a roaming UE and a non-roaming UE using the same access network may be given the same IP address.
If an internal IP address collision below a NAT function occurs, the reverse mapping for downlink IP packets of two flows to different hosts is that the external addresses of both flows are replaced by the identical source internal IP addresses (cf. FIG. 3, resulting in E-IPa→I-IPi, E-IPb→I-IPi; the source ports may be replaced in that EPorta→I-Portx and E-Portb→Portγ). Therefore, the reverse mapping at the NAT function provides a correct IP address/port number combination for the IP downlink packets. However, the information regarding which host the IP downlink packets belongs gets lost. Thus, in, e.g., a 3GPP communication network, the downlink IP data packets cannot be inserted back into the correct GTP-U tunnels. Hence, a TOF using a known NAT function cannot solve the problem of internal IP address collision. Moreover, for the above examples, no technique of avoiding IP address collision below a TOF is known.